同一顆模型，四種跑法

模型庫就緒之後，下一個問題是用什麼東西才能跑把地端 AI 模型跑起來呢。這個東西就叫做推論引擎，它負責把權重載入記憶體、排程運算、管理 KV cache，最後把 token 一個個吐出來。

地端 AI 領域中，最常見的四大天王名字分別是 llama.cpp、Ollama、vLLM 與 TensorRT-LLM。它們都能跑同一款模型，但這四個推論引擎的設計目標大不同，選錯引擎的話，後果輕則效能打折，重則整個使用體驗跟你的場景對不搭。今天先把這四者的定位講清楚，協助建立一個「什麼場景該選什麼」的判斷概念。最後再補上一個近期因為量化模型熱門後的新整合型選擇 Unsloth ，他們最近的 Unsloth Desktop 與 Unsloth Studio，整合了本機 AI 模型執行、Dynamic 2.0 GGUF 量化與無需程式碼的微調功能，最高號稱能 70% 的 VRAM 需求，並將訓練速度提升高達 2 倍。

四個引擎，四種性格

llama.cpp：極簡主義的萬用瑞士刀

llama.cpp 是純 C/C++ 實作的推論引擎，GGUF 量化格式的原生家園。它的哲學是極簡與可攜，沒有 Python 依賴地獄，一個執行檔就能跑，從樹莓派到資料中心 GPU 都是它的地盤。CPU 與 GPU 混合推論是它的獨門絕活，模型比 VRAM 大的時候可以把部分層放到系統記憶體，雖然慢，但至少跑得起來。

它的甜蜜點是單用戶場景，一個人、一台機器、一次一個請求。搭配內建的 llama-server 也能提供 OpenAI 相容 API，輕量服務完全夠用。弱項是高並發、多用戶同時使用時，其吞吐排程不是它的設計目標，所以會很慢。

Ollama：把 llama.cpp 包成易用軟體

社群中非常熱門的 Ollama 底層長期建構在 llama.cpp 生態之上，它的價值不在引擎本身，而在體驗封裝，做到非常簡單，使用者只要下一行指令 Ollama 後面接上用途，就能夠拉模型、跑模型、切模型，模型庫管理、API 服務、多模型切換都幫你打理好。選擇它的代價是對底層參數的控制粒度較粗，以及版本跟進上游的節奏由 Ollama 決定，不會比 llama.cpp 更新快。而部分社群用戶對它是比較反感的，其團隊被指控將底層核心技術（如長期依賴的 llama.cpp）包裝成自家原創，加上預設開機自動啟動等強制性行為，以及在快速商業化與資本化過程中引發的開源割韭菜爭議與安全性疑慮。

它的定位是「想用地端模型，但不想研究推論引擎的人」。這個系列既然都在研究推論引擎了，Ollama 之後出場的機會不多，但把它放進框架是必要的，因為對很多讀者來說它是最簡單的答案。比方說 Mac 用戶，可以很方便地使用 Ollama ，它還支援 MLX 加速，對 Mac 用戶是友善的。而 Windows 用戶也可以裝它的桌面版，搭配著名的 Open WebUI 做不錯的企業內、家用個人 ChatGPT Style 型態網頁來提供 AI 問答功能。

vLLM：為吞吐而生的服務引擎

vLLM 出身美國科技名校 UC 柏克萊，核心武器是 PagedAttention 與 continuous batching。前者把 KV cache 做成分頁管理大幅減少記憶體碎片，後者讓不同請求的生成動態併批，GPU 不會因為等待最慢的請求而空轉。這兩招疊起來，多用戶並發場景的總吞吐量可以是單請求引擎的數倍以上。

它的甜蜜點是「一台機器服務多個使用者或多個應用」，也就是把地端模型當成正式服務來經營的場景。NVIDIA 為 DGX Spark 維護官方 vLLM 容器映像，這也是本系列實測的重點引擎之一。選它的代價，是安裝與設定比 llama.cpp 重，量化格式支援以 safetensors 生態（AWQ、FP8 等）為主，GGUF 格式的模型不是它的主場。

TensorRT-LLM：把硬體榨到最後一滴

TensorRT-LLM 是 NVIDIA 自家的推論最佳化框架，把模型編譯成針對特定 GPU 架構深度最佳化的引擎，prefill 效能與低延遲是它的強項。選擇它的代價也最沉重，編譯流程繁瑣、彈性最低、換模型換量化就要重新編譯，生態綁定 NVIDIA。

它的定位是生產環境的極致效能場景，願意用工程複雜度換最後那一段效能的人才需要它。在 DGX Spark 上它有原生支援，我們也會實測它與 vLLM 的差距到底值不值得那些麻煩。

一張表收攏

第五人格：模型專用引擎 ds4

四大引擎之外，還有一種值得認識的路線，第五人格，好吧，不是，今天要介紹的代表作是著名的 Redis 之父 antirez 的 ds4（DwarfStar）。它與前四者的哲學完全相反，不做通用引擎，一次只深度支援一個模型，目前是 DeepSeek V4 Flash 與 PRO。純 C 實作、完全自包含，不是任何引擎的包裝，但作者在 README 中誠懇致謝 llama.cpp 與 GGML 開出的路，我覺得這是開源開發者很不錯的素質，繼往開來，大家都是建立在前人的貢獻下，繼續成長往前走。社群喜歡和尊敬的是這類開發者，而不是那種大家可能看不慣的收割仔。

垂直特化換來的是一般通用引擎給不了的東西，針對 DeepSeek V4 的 KV cache 設計深度最佳化、把 KV cache 當成一級磁碟公民的 SSD 串流模式、原生整合的 coding agent，以及同時提供 OpenAI 與 Anthropic 相容 API 的 ds4-server。除了對 Mac 設備友善，對 DGX Spark 使用者也還有一個貼心細節，Makefile 直接內建 make cuda-spark 建置目標針對 GB10 特調，官方效能表也列有 DGX Spark 的實測成績。它的 2-bit imatrix 量化專為 96GB 到 128GB 記憶體等級的機器設計，正好就是單台 DGX Spark 的甜蜜點。

這條路線的取捨很清楚，模型換代時引擎要跟著重寫，換來的是把單一模型在特定硬體上做到最好。當你的日常主力就是那一顆模型時，這個取捨非常划算。

我的環境怎麼選：一個實際的混搭案例

看完框架，講我自己的實際配置吧，畢竟真實環境下，幾乎都是混搭。

目前 Spark 1 上常駐的 DeepSeek V4 Flash 0731 正是跑在 ds4-server 上，以 2-bit imatrix 量化服務我的日常查詢與自動化流程。單一主力模型、單用戶場景，模型專用引擎就是合理選擇。
而當需要實測多模型併發服務、以及雙 Spark 合體跑大模型的分散式推論，我使用的主角就會換成 vLLM。同一套硬體，不同工作負載，不同引擎，視情況滾動式調整，與時俱進，這才是地端部署的常態。

給讀者的選型捷徑，我這邊簡單濃縮成三句話。自己一個人用，從 llama.cpp 或 Ollama 開始。要服務一群人或一堆應用，直上 vLLM。前兩者都跑順了還嫌不夠快，才考慮 TensorRT-LLM。

OpenAI 相容 API：四條路的共同終點

最後補一個好消息。四個引擎殊途同歸，最後都提供 OpenAI 相容的 API 端點。這代表你的上層應用（聊天介面、Agent 框架、自動化腳本）只要會講 OpenAI API 這套通用語言，底下的引擎可以隨時抽換，應用程式一行不用改。這個解耦是地端架構彈性的關鍵，選引擎的決策因此永遠可以反悔，我的實作與測試也會告訴我們什麼時候該反悔。 : P

補充：微調工具鏈也在 GB10 上就位了

最後想再補一個與引擎選型平行的好消息，這兩天發生的。除了 AI 推論之外，微調工具鏈對 GB10 的支援也有更好的實作誕生，也就是可採用 Unsloth Studio 支援在 GB10 架構的 ARM64/Linux 環境（如 DGX Spark）上安裝執行，官方與開發者社群有對應的安裝支援與討論，裝好後可透過 nvidia-smi 確認抓到 GB10 與 CUDA 支援，我自己視覺得還不錯用。

實務上要留意相依性問題，部分使用者在 GB10 的 ARM64 環境安裝時，會遇到特定套件（例如 torchcodec 的 wheel 相依性）需要手動微調，或改用更新版的安裝腳本解決。完整的安裝實測與微調實戰，我會之後再分享給大家。

明天預告

框架建好了，明天讓我自己喜歡用的第一款模型正式上線，從模型庫拉權重、啟動服務、到 API 打通的完整流程走一遍，第一週的架構奠基與概念解說，希望各位能喜歡和滿意。

我們 Day 7 見。

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜Day 4|開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程